freescale semiconductor, inc., 2006, 2007. all rights reserved. freescale semiconductor mask set errata mse9s08qg8_3m77b rev. 2, 5/2007 mask set errata for mask 3m77b introduction this mask set errata applies to the mask 3m77b for these products: mc9s08qg8 MC9S08QG4 mcu device mask set identification the mask set is identified by a 5-character code consisting of a version number, a letter, two numerical digits, and a letter, for example 3m77b. all standard devices are marked with a mask set number and a date code. possible high current in stop mode if kbi/irq enabled se96b-irq_kbi description in stop mode, with the irq or kbi pin functions enabled but the irq/kbi interrupt disabled, a toggle on the irq/kbi pin will turn on the voltage regulator and oscillator, causing the clocks to run. this results in higher stop i dd . in this condition, the cpu is halted (as if in wait mode) and the chip level interrupt is not generated. this higher current condition can also happen if the flag is set at time of stop entry.
mask set errata for 9s08qg8, mask 3m77b 2 freescale semiconductor workaround this problem applies to the non-interrupt functions that are shared with irq and kbi functions. because interrupts from irq or kbi are disabled, these pins are not used to wake up the mcu from stop. to prevent signals on irq or kbi from causing an unexpected partial wakeup from stop in these applications, disable the irq and kbi modules just before entering stop mode. also verify that any previous interrupt flags associated with irq and kbi have been cleared. unexpected flash block protection errors se133-flash description if a portion of the nonvolatile memory (nvm) is block protected, unexpected flash block protect violation (fpviol) errors can result. these errors can occur during an attempt to program or erase locations in areas of the nvm that are not block protected. software methods can be used to avoid this potential problem. the problem is more likely to be seen on devices that have multiple nonvolatile blocks, including devices with two or more separate flash blocks or with flash plus eeprom. if block protection is not enabled, no errors occur. this error is related to logic that compares current block protection settings to an internally latched address. this internal address is written (latched) at reset, at the end of most flash commands, and whenever there is a write to a location in nvm. if a read access to the partially protected nvm is performed immediately before the write to unprotected memory that starts a new flash command, the erroneous address that was previously in the internal latch can cause a false indication of a protection violation. a short sequence of instructions can be performed before starting normal flash commands to ensure that the address in the internal latch is not a protected address. workarounds the preferred workaround starts a command to a known unprotected address (which internally latches the known-unprotected address), forces an access error to abort that command, and then clears the resulting error flags before starting any new flash command. this workaround assumes the h:x index register points to the location or sector you want to program or erase, and accumulator a has the data value you plan to write to that location. start your program or erase routine with the following instructions. sta ,x ;latch the unprotected address from h:x nop ;brief delay to allow the command state machine to start sta ,x ;intentionally cause an access error to abort this command psha ;temporarily save data value lda #$30 ;1? in pviol and accerr bit positions sta fstat ;clear any error flags pula ;restore data value sta ,x ;step 1 write data to start new command
mask set errata for 9s08qg8, mask 3m77b freescale semiconductor 3 the only new instructions compared to the normal routine for flash commands are the first three instructions, which take three bytes of code space and five bus cycles. these instructions may be located anywhere in memory, including in the protected area of the flash memory. ics v1 can cause a very short clock pulse se128a-icsv1 description the ics module v1 when configured with the fll enabled and with bdiv set to divide-by one can sometimes produce a very short clock pulse. this short clock pulse can cause the device to malfunction. the short clock pulse is caused when the digitally controlled oscillator (dco) crosses a filter value boundary when compensating for output frequency error. the filter value is not in the memory map and cannot be read by user code. when operating from the internal reference clock, certain trim values can cause the error more often. the trim value for any particular clock frequency is unique to each device. the temperature coefficient of the dco is such that the unique reference frequency causing the error, either internally or externally generated, will not be constant over temperature. workarounds if using fll enabled with internal reference (fei) or fll enabled with external reference (fee) modes, operate the device with a bus frequency equal to or below 5 mhz. this is accomplished by setting bdiv divide-by value to two or higher (bdiv[1,0] bit field value of 01, 10 or 11). use the ics in any of the modes with the fll disabled. this includes: fll bypassed internal (fbi), fll bypassed internal low power (fbilp), fll bypassed external (fbi), fll bypassed external low power (fbelp) modes. (not all devices have extal and xtal pins available to run the device with an external reference.) pwm boundary case issues in hcs08 timer pwm module (tpm) se110-tpm this errata describes boundary case issues that primarily affect the center-aligned pwm mode of operation. while investigating these issues, additional, less significant, issues were discovered. these will be explained, although they should not cause any significant problems in normal applications. in center-aligned pwm mode, the timer counter counts up until it reaches the modulo value in tpmmodh:tpmmodl, reverses direction, and then counts down until it reaches zero, where it reverses and counts up again. a period of the pwm output is centered around the leading edge of the zero count and the period is considered to start when the count changes from tpmmodh:tpmmodl? to tpmmodh:tpmmodl (the same point where the counter changes from up-counting to down-counting). the zero value and the maximum modulo value occur for only one timer count cycle each, while all other
mask set errata for 9s08qg8, mask 3m77b 4 freescale semiconductor values occur twice (once during the down-counting phase and again during the up-counting phase). therefore, the total period of the pwm signal is two times the value in tpmmodh:tpmmodl. the value on each tpm timer output pin is controlled by an internal flip-flop that is cleared at reset but is not readable by software. these internal flip-flops change state when timer output compare events or pwm duty cycle compare events occur (when the channel value registers match the timer count registers). this leads to these outputs remaining in a previous state until a compare event occurs after changing the configuration of the timer system. when the timer is initialized the first time after a reset, the state of these output flip-flops is known to be reset (logic low). if the configuration is changed after the channel has been running in another configuration for some period of time, you sometimes do not know the state of these internal flip-flops (and therefore the state of the timer output pins) until a new channel value register compare event occurs. there is nothing improper about these periods before the first event occurs, however some users might be surprised the first time they notice this behavior. when the mcu is reset, the count (tpmcnth:tpmcntl) is reset to 0x0000. if the timer is configured for center-aligned pulse-width modulation (pwm) and then the clock is started, this corresponds to the middle of a pwm period. if the internal flip-flop corresponding to the output was at the inactive level when the pwm started, this would appear as if there was an extra half period of delay before the first full pwm cycle started. if the internal flip-flop corresponding to the output happened to be at the active level when this pwm was started, a pulse equivalent to half of a normal duty cycle pulse could be produced at the pwm output pin. there are eight cases discussed in this errata: cases 1 and 2 these are two error cases near the 100% duty cycle boundary. the first is when the channel value registers are set equal to the modulo value. the second is when the channel value registers are set to one less than the modulo value. cases 3, 4, and 5 ?these cases are related to changing the channel value to or from 0x0000. the errors depend upon whether this is done during the first or second half of the center-aligned pwm period. in all of these cases, the workaround strategy is to produce 0% duty cycle with a negative channel value instead of using the 0x0000 value. this can be done by checking any value that is about to be written to the channel value registers, and then decrement the 16-bit value or the high-order byte of the value before writing it to the channel value registers. this produces the desired 0% duty cycle and avoids the problems related to a zero in the channel value registers. case 6 although this behavior wasn? discussed in the data sheet, the operation is different than some users might expect. in edge-aligned pwm mode, when the channel value is changed from zero to a non-zero value, the new pwm settings can take an extra half pwm period to take effect. it is unlikely that this would cause any problems in any practical application system. case 7 this case is more of a clarification of an unusual situation rather than a design problem. this case happens when the prescale factor is changed during operation and only affects center- aligned pwm. it would be very unusual to change the prescale setting after it is set during reset initialization. the prescale flip-flops are not reset when the prescale setting is changed, so the first prescaled clock period after a change may be shorter or longer than expected. case 8 this case would only arise when a series of unlikely events happened to occur. it affects only center-aligned pwm mode if the timer counter is stopped, reset, and restarted when the count value happened to be equal to the tpmxmodh:tpmxmodl value. because the timer counter would not normally be stopped during operation in center-aligned pwm mode, this case should never arise in a practical application.
mask set errata for 9s08qg8, mask 3m77b freescale semiconductor 5 case 1: center-aligned pwm channel value (tpmxcnvh:tpmxcnvl) = modulo value (tpmxmodh:tpmxmodl) description this should produce 100% duty cycle where the tpm output pin remains at the active level continuously. instead, the output remains at the inactive level, which corresponds to 0% duty cycle. workarounds check any value that is about to be written to the channel value registers. if the value is the same as the modulo value, increment the value before writing it to the channel value register. this workaround will work for any modulo value that is greater than zero and less than 0x7fff. setting the channel value to any 2? complement negative value (0x8000 through 0xffff) results in 0% duty cycle as expected and described in the original tpm documentation. another workaround would be to choose not to use 100% duty cycle in the application. not all applications require the range to include the 100% duty cycle case. case 2: center-aligned pwm channel value (tpmxcnvh:tpmxcnvl) = modulo value minus 1 (tpmxmodh:tpmxmodl ?1) description this should produce almost 100% duty cycle where the tpm output pin remains at the active level for [(tpmxcnvh:tpmxcnvl 100)/(tpmxmodh:tpmxmodl)]% of the period. instead, the output remains at the inactive level which corresponds to 0% duty cycle. workarounds reduce the prescale factor by a factor of two and then multiply the modulo and channel value settings by a factor of two. in this way, the frequency and resolution of the pwm output remain the same but channel values are always even numbers and are never equal to the modulo setting minus one. consider the case of a 20-mhz bus frequency, 25-khz pwm frequency, and 0.25% resolution on the duty cycle. before making the adjustments suggested in this workaround, you could have the following setup: set the modulo to 400 and the prescale factor in ps2:ps1:ps0 to divide by 2 (0:0:1). each step of the channel value from 0???98?99?00 would increase the duty cycle by 0.25%. increasing the modulo value to 800 and reducing the prescale factor to divide-by one, would still produce the same period or pwm frequency. if the original channel values were multiplied by two (shift left one bit position) before writing them to the channel value register, the resolution would still be 0.25% per step of the channel value, but the channel values would step by 2 each time as in 0-2-4-6?96-798-800. with this workaround, the channel value would never be equal to the modulo value minus one, and the error condition would not arise.
mask set errata for 9s08qg8, mask 3m77b 6 freescale semiconductor with common hcs08 bus frequencies, practical pwm frequencies, and reasonable resolution requirements, there is enough speed and flexibility in the tpm system so this workaround should work well with all except the most unusual application systems. another workaround would be to limit the range of allowed values in the channel value register so it does not include the tpmxmodh:tpmxmodl or (tpmxmodh:tpmxmodl 1) values. not all applications require the range to include these values. case 3: center-aligned pwm tpmxcnvh:tpmxcnvl changed from 0x0000 to a non-zero value description this case occurs only while the counter is counting down (first half of the center-aligned pwm period). the pwm output changes to the active level at the middle of the current pwm period as the count reaches 0x0000 instead of waiting for the start of a new pwm period to begin using the new duty cycle setting. workaround use a negative channel value instead of 0x0000 to produce 0% duty cycle. this can be done by checking any value that is about to be written to the channel value registers, and then decrementing the 16-bit value or the high-order byte of this value before writing it to the channel value registers. this produces the desired 0% duty cycle and it avoids the problems related to a zero in the channel value registers. case 4: center-aligned pwm tpmxcnvh:tpmxcnvl changed from a non-zero value to 0x0000 description this case occurs only while the counter is counting up (second half of the center-aligned pwm period) but before the count reaches the channel value setting in tpmxcnvh:tpmxcnvl. the pwm output remains at the active level until the end of the current pwm period instead of finishing the current pwm period using the old channel value setting. workaround use a negative channel value instead of 0x0000 to produce 0% duty cycle. this can be done by checking any value that is about to be written to the channel value registers, and then decrement the 16-bit value or the high-order byte of this value before writing it to the channel value registers. this produces the desired 0% duty cycle and it avoids the problems related to a zero in the channel value registers.
mask set errata for 9s08qg8, mask 3m77b freescale semiconductor 7 case 5: center-aligned pwm tpmxcnvh:tpmxcnvl changed from 0x0000 to a non-zero value description this case occurs only while the counter is counting down (first half of the center-aligned pwm period) and then tpmxcnvh:tpmxcnvl is changed back to 0x0000 during the first half of the next pwm period (while the counter is counting down). this is a very unlikely case in any practical application. the pwm output changes to the active level at the middle of the first pwm period as the count reaches 0x0000 instead of waiting for the start of a new pwm period to begin using the new duty cycle setting, and then the output remains active until the end of the second pwm period. in this very unusual case, the pwm output remains active for one and one-half pwm periods rather than remaining inactive for the first pwm period and then active for 2 tpmxcnvh:tpmxcnvl during the next pwm period. workaround use a negative channel value instead of 0x0000 to produce 0% duty cycle. this can be done by checking any value that is about to be written to the channel value registers, and then decrementing the 16-bit value or the high-order byte of this value before writing it to the channel value registers. this produces the desired 0% duty cycle and it avoids the problems related to a zero in the channel value registers. case 6: edge-aligned pwm tpmxcnvh:tpmxcnvl changed from 0x0000 to a non-zero value description this is a minor issue related to edge-aligned pwm when duty cycle is changed from 0x0000 to a non- zero value. this issue is a specification clarification rather than a design error. in this case, the channel value update occurs at the same time as the new pwm period begins, but due to circuit delays, the update occurs slightly too late for the new duty cycle to take effect for that pwm period and an extra period of 0% duty cycle is produced. this causes the new pwm duty cycle to take effect one pwm period later than expected. this should not cause any application problems so the data book functional description will be changed to clarify this situation. case 7: changing the counter prescaler while the tpm counter is disabled description this case would not arise in most applications because it would be unusual to change the prescaler at any time other than initial timer setup after reset. 1. tpm counter was previously running 2. counting is stopped by writing 0:0 to clks[1:0] 3. change prescale value ps[2:1:0] to a different value while keeping clocks off (clks[1:0] = 0:0) 4. clear the counter by writing any value to tpmxcnth:tpmxcntl
mask set errata for 9s08qg8, mask 3m77b 8 freescale semiconductor 5. turn clocks back on by writing to clks[1:0] unexpected operation: the prescaler divider flip-flops begin counting from the prior value rather than starting from zero. this can result in the counter detecting the first clock edge after restarting, either earlier or later than expected. case 8: center-aligned pwm, counter is stopped, reset, and restarted when counting up and count equals the modulo value description this case is extremely unlikely to occur in any practical application because it would be very unusual to stop or reset the tpm counter while using center-aligned pwm mode. 1. tpm counter is counting up in center-aligned pwm mode (second half of a pwm period) 2. counter is stopped (write clks[1:0] = 0:0) when count equals modulo value (the direction would normally change from up counting to down counting at the next clock edge) 3. counter is reset to 0x0000 by writing any value to tpmxcnth:tpmxcntl 4. counter is turned on again by writing to clks[1:0] unexpected operation: because the internal up/down indicator was not cleared when the counter was reset, the counter begins counting down from 0x0000 to 0xffff?xfffe this causes the timing of the first pwm period after the counter reset to be longer than expected.
|
